React Testing Library: 글로벌 팀을 위한 컴포넌트 테스팅 모범 사례

끊임없이 진화하는 웹 개발 세계에서 React 애플리케이션의 신뢰성과 품질을 보장하는 것은 매우 중요합니다. 이는 다양한 사용자 기반과 접근성 요구사항을 가진 프로젝트를 진행하는 글로벌 팀에게 특히 그렇습니다. React Testing Library(RTL)는 컴포넌트 테스팅에 강력하고 사용자 중심적인 접근 방식을 제공합니다. 구현 세부 사항에 초점을 맞추는 기존의 테스팅 방법과 달리, RTL은 사용자가 컴포넌트와 상호작용하는 것처럼 테스트하도록 장려하여 더 견고하고 유지보수하기 쉬운 테스트를 만들 수 있게 합니다. 이 종합 가이드에서는 글로벌 사용자를 위한 애플리케이션 구축에 초점을 맞춰 React 프로젝트에서 RTL을 활용하기 위한 모범 사례를 자세히 살펴보겠습니다.

왜 React Testing Library를 사용해야 할까요?

모범 사례를 살펴보기 전에, 왜 RTL이 다른 테스팅 라이브러리와 차별화되는지 이해하는 것이 중요합니다. 다음은 몇 가지 주요 장점입니다:

• 사용자 중심 접근 방식: RTL은 사용자 관점에서 컴포넌트를 테스트하는 것을 우선시합니다. 사용자가 사용하는 것과 동일한 방식(예: 버튼 클릭, 입력 필드에 타이핑)으로 컴포넌트와 상호작용하여 더 현실적이고 신뢰할 수 있는 테스팅 경험을 보장합니다.
• 접근성 중심: RTL은 장애를 가진 사용자를 고려하는 방식으로 컴포넌트를 테스트하도록 장려하여 접근성 있는 컴포넌트 작성을 촉진합니다. 이는 WCAG와 같은 글로벌 접근성 표준과 일치합니다.
• 유지보수 비용 감소: 구현 세부 사항(예: 내부 상태, 특정 함수 호출) 테스트를 피함으로써, RTL 테스트는 코드를 리팩토링할 때 깨질 가능성이 적습니다. 이는 더 유지보수하기 쉽고 복원력 있는 테스트로 이어집니다.
• 개선된 코드 설계: RTL의 사용자 중심 접근 방식은 사용자가 컴포넌트와 어떻게 상호작용할지 생각하게 하므로, 종종 더 나은 컴포넌트 설계로 이어집니다.
• 커뮤니티와 생태계: RTL은 크고 활발한 커뮤니티를 자랑하며, 풍부한 리소스, 지원, 확장 기능을 제공합니다.

테스팅 환경 설정하기

RTL을 시작하려면 테스팅 환경을 설정해야 합니다. 다음은 Jest와 RTL이 사전 구성된 Create React App(CRA)을 사용한 기본 설정입니다:

npx create-react-app my-react-app
cd my-react-app
npm install --save-dev @testing-library/react @testing-library/jest-dom

설명:

• `npx create-react-app my-react-app`: Create React App을 사용하여 새 React 프로젝트를 생성합니다.
• `cd my-react-app`: 새로 생성된 프로젝트 디렉토리로 이동합니다.
• `npm install --save-dev @testing-library/react @testing-library/jest-dom`: 필요한 RTL 패키지를 개발 의존성으로 설치합니다. `@testing-library/react`는 핵심 RTL 기능을 제공하고, `@testing-library/jest-dom`은 DOM 작업을 위한 유용한 Jest 매처를 제공합니다.

CRA를 사용하지 않는 경우, Jest와 RTL을 별도로 설치하고 RTL을 사용하도록 Jest를 구성해야 합니다.

React Testing Library를 사용한 컴포넌트 테스팅 모범 사례

1. 사용자 상호작용을 모방하는 테스트 작성하기

RTL의 핵심 원칙은 사용자가 하는 것처럼 컴포넌트를 테스트하는 것입니다. 이는 내부 구현 세부 사항보다는 사용자가 보고 수행하는 것에 초점을 맞추는 것을 의미합니다. RTL이 제공하는 `screen` 객체를 사용하여 텍스트, 역할 또는 접근성 레이블을 기반으로 요소를 쿼리하세요.

예시: 버튼 클릭 테스트하기

간단한 버튼 컴포넌트가 있다고 가정해 봅시다:

// Button.js
import React from 'react';

function Button({ onClick, children }) {
  return {children};
}

export default Button;

RTL을 사용하여 테스트하는 방법은 다음과 같습니다:

// Button.test.js
import React from 'react';
import { render, screen, fireEvent } from '@testing-library/react';
import Button from './Button';

describe('Button Component', () => {
  it('클릭 시 onClick 핸들러를 호출한다', () => {
    const handleClick = jest.fn();
    render(Click Me);

    const buttonElement = screen.getByText('Click Me');
    fireEvent.click(buttonElement);

    expect(handleClick).toHaveBeenCalledTimes(1);
  });
});

설명:

• `render(Click Me)`: 모의 `onClick` 핸들러로 Button 컴포넌트를 렌더링합니다.
• `screen.getByText('Click Me')`: "Click Me" 텍스트를 포함하는 요소를 문서에서 쿼리합니다. 이것이 사용자가 버튼을 식별하는 방법입니다.
• `fireEvent.click(buttonElement)`: 버튼 요소에서 클릭 이벤트를 시뮬레이션합니다.
• `expect(handleClick).toHaveBeenCalledTimes(1)`: `onClick` 핸들러가 한 번 호출되었는지 확인합니다.

이것이 구현 세부 사항을 테스트하는 것보다 나은 이유: Button 컴포넌트를 다른 이벤트 핸들러를 사용하거나 내부 상태를 변경하도록 리팩토링한다고 상상해 보세요. 특정 이벤트 핸들러 함수를 테스트했다면 테스트가 깨졌을 것입니다. 사용자 상호작용(버튼 클릭)에 초점을 맞춤으로써, 테스트는 리팩토링 후에도 유효하게 유지됩니다.

2. 사용자 의도에 기반한 쿼리 우선순위 정하기

RTL은 요소를 찾기 위한 다양한 쿼리 메서드를 제공합니다. 다음 쿼리들은 사용자가 컴포넌트를 인식하고 상호작용하는 방식을 가장 잘 반영하므로 이 순서대로 우선순위를 정하세요:

• getByRole: 이 쿼리는 가장 접근성이 높으며 첫 번째 선택이어야 합니다. ARIA 역할(예: button, link, heading)을 기반으로 요소를 찾을 수 있습니다.
• getByLabelText: 입력 필드와 같은 특정 레이블과 연관된 요소를 찾는 데 사용합니다.
• getByPlaceholderText: 플레이스홀더 텍스트를 기반으로 입력 필드를 찾는 데 사용합니다.
• getByText: 텍스트 콘텐츠를 기반으로 요소를 찾는 데 사용합니다. 여러 곳에 나타날 수 있는 일반적인 텍스트는 피하고 구체적으로 사용하세요.
• getByDisplayValue: 현재 값을 기반으로 입력 필드를 찾는 데 사용합니다.

예시: 폼 입력 테스트하기

// Input.js
import React from 'react';

function Input({ label, placeholder, value, onChange }) {
  return (
    

      {label}
      
    
  );
}

export default Input;

권장 쿼리 순서를 사용하여 테스트하는 방법은 다음과 같습니다:

// Input.test.js
import React from 'react';
import { render, screen, fireEvent } from '@testing-library/react';
import Input from './Input';

describe('Input Component', () => {
  it('사용자가 입력할 때 값이 업데이트된다', () => {
    const handleChange = jest.fn();
    render();

    const inputElement = screen.getByLabelText('Name');
    fireEvent.change(inputElement, { target: { value: 'John Doe' } });

    expect(handleChange).toHaveBeenCalledTimes(1);
    expect(handleChange).toHaveBeenCalledWith(expect.objectContaining({ target: { value: 'John Doe' } }));
  });
});

설명:

• `screen.getByLabelText('Name')`: `getByLabelText`를 사용하여 "Name" 레이블과 연관된 입력 필드를 찾습니다. 이것이 입력을 찾는 가장 접근성 있고 사용자 친화적인 방법입니다.

3. 구현 세부 사항 테스트 피하기

앞서 언급했듯이, 내부 상태, 함수 호출 또는 특정 CSS 클래스를 테스트하는 것을 피하세요. 이것들은 변경될 수 있고 깨지기 쉬운 테스트로 이어질 수 있는 구현 세부 사항입니다. 컴포넌트의 관찰 가능한 동작에 집중하세요.

예시: 상태 직접 테스트 피하기

특정 상태 변수가 업데이트되었는지 테스트하는 대신, 해당 상태에 따라 컴포넌트가 올바른 출력을 렌더링하는지 테스트하세요. 예를 들어, 컴포넌트가 부울 상태 변수에 따라 메시지를 표시하는 경우, 상태 변수 자체를 테스트하는 대신 메시지가 표시되거나 숨겨지는지를 테스트하세요.

4. 특정 사례에 `data-testid` 사용하기

일반적으로 `data-testid` 속성을 사용하지 않는 것이 가장 좋지만, 도움이 될 수 있는 특정 사례가 있습니다:

• 의미 있는 의미가 없는 요소: 의미 있는 역할, 레이블 또는 텍스트가 없는 요소를 타겟팅해야 하는 경우 `data-testid`를 사용할 수 있습니다.
• 복잡한 컴포넌트 구조: 복잡한 컴포넌트 구조에서 `data-testid`는 깨지기 쉬운 선택자에 의존하지 않고 특정 요소를 타겟팅하는 데 도움이 될 수 있습니다.
• 접근성 테스트: `data-testid`는 Cypress나 Playwright와 같은 도구로 접근성 테스트를 하는 동안 특정 요소를 식별하는 데 사용될 수 있습니다.

예시: `data-testid` 사용하기

// MyComponent.js
import React from 'react';

function MyComponent() {
  return (
    

      
This is my component.
    
  );
}

export default MyComponent;

// MyComponent.test.js
import React from 'react';
import { render, screen } from '@testing-library/react';
import MyComponent from './MyComponent';

describe('MyComponent', () => {
  it('컴포넌트 컨테이너를 렌더링한다', () => {
    render();
    const containerElement = screen.getByTestId('my-component-container');
    expect(containerElement).toBeInTheDocument();
  });
});

중요: `data-testid`는 드물게, 그리고 다른 쿼리 메서드가 적합하지 않을 때만 사용하세요.

5. 의미 있는 테스트 설명 작성하기

명확하고 간결한 테스트 설명은 각 테스트의 목적을 이해하고 실패를 디버깅하는 데 중요합니다. 테스트가 무엇을 검증하는지 명확하게 설명하는 서술적인 이름을 사용하세요.

예시: 좋은 테스트 설명 vs. 나쁜 테스트 설명

나쁨: `it('작동한다')`

좋음: `it('올바른 인사 메시지를 표시한다')`

더 좋음: `it('name prop이 제공되지 않았을 때 "Hello, World!" 인사 메시지를 표시한다')`

더 좋은 예시는 특정 조건 하에서 컴포넌트의 예상되는 동작을 명확하게 설명합니다.

6. 테스트를 작고 집중적으로 유지하기

각 테스트는 컴포넌트 동작의 단일 측면을 검증하는 데 집중해야 합니다. 여러 시나리오를 다루는 크고 복잡한 테스트를 작성하지 마세요. 작고 집중된 테스트는 이해하고, 유지보수하고, 디버깅하기 더 쉽습니다.

7. 테스트 대역(Mocks and Spies) 적절하게 사용하기

테스트 대역은 테스트 중인 컴포넌트를 의존성으로부터 격리하는 데 유용합니다. 모의(mock)와 스파이(spy)를 사용하여 외부 서비스, API 호출 또는 다른 컴포넌트를 시뮬레이션하세요.

예시: API 호출 모킹하기

// UserList.js
import React, { useState, useEffect } from 'react';

function UserList() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    async function fetchUsers() {
      const response = await fetch('/api/users');
      const data = await response.json();
      setUsers(data);
    }

    fetchUsers();
  }, []);

  return (
    

      {users.map(user => (
        
{user.name}
      ))}
    
  );
}

export default UserList;

// UserList.test.js
import React from 'react';
import { render, screen, waitFor } from '@testing-library/react';
import UserList from './UserList';

global.fetch = jest.fn(() =>
  Promise.resolve({
    json: () => Promise.resolve([
      { id: 1, name: 'John Doe' },
      { id: 2, name: 'Jane Smith' },
    ]),
  })
);

describe('UserList Component', () => {
  it('사용자 목록을 가져와 표시한다', async () => {
    render();

    // 데이터가 로드될 때까지 기다림
    await waitFor(() => screen.getByText('John Doe'));

    expect(screen.getByText('John Doe')).toBeInTheDocument();
    expect(screen.getByText('Jane Smith')).toBeInTheDocument();
  });
});

설명:

• `global.fetch = jest.fn(...)`: `fetch` 함수를 모킹하여 미리 정의된 사용자 목록을 반환합니다. 이를 통해 실제 API 엔드포인트에 의존하지 않고 컴포넌트를 테스트할 수 있습니다.
• `await waitFor(() => screen.getByText('John Doe'))`: "John Doe" 텍스트가 문서에 나타날 때까지 기다립니다. 데이터가 비동기적으로 가져오기 때문에 이 과정이 필요합니다.

8. 엣지 케이스와 오류 처리 테스트하기

성공적인 경로만 테스트하지 마세요. 엣지 케이스, 오류 시나리오, 경계 조건을 테스트해야 합니다. 이는 잠재적인 문제를 조기에 식별하고 컴포넌트가 예기치 않은 상황을 우아하게 처리하도록 보장하는 데 도움이 됩니다.

예시: 오류 처리 테스트하기

API에서 데이터를 가져오고 API 호출이 실패하면 오류 메시지를 표시하는 컴포넌트를 상상해 보세요. API 호출이 실패했을 때 오류 메시지가 올바르게 표시되는지 확인하는 테스트를 작성해야 합니다.

9. 접근성에 집중하기

접근성은 포용적인 웹 애플리케이션을 만드는 데 중요합니다. RTL을 사용하여 컴포넌트의 접근성을 테스트하고 WCAG와 같은 접근성 표준을 충족하는지 확인하세요. 몇 가지 주요 접근성 고려 사항은 다음과 같습니다:

• 시맨틱 HTML: 시맨틱 HTML 요소(예: ``, `
• ARIA 속성: 특히 커스텀 컴포넌트의 경우, 요소의 역할, 상태 및 속성에 대한 추가 정보를 제공하기 위해 ARIA 속성을 사용하세요.
• 키보드 네비게이션: 모든 상호작용 요소가 키보드 네비게이션을 통해 접근 가능한지 확인하세요.
• 색상 대비: 저시력 사용자가 텍스트를 읽을 수 있도록 충분한 색상 대비를 사용하세요.
• 스크린 리더 호환성: 스크린 리더로 컴포넌트를 테스트하여 시각 장애가 있는 사용자에게 의미 있고 이해할 수 있는 경험을 제공하는지 확인하세요.

예시: `getByRole`로 접근성 테스트하기

// MyAccessibleComponent.js
import React from 'react';

function MyAccessibleComponent() {
  return (
    X
  );
}

export default MyAccessibleComponent;

// MyAccessibleComponent.test.js
import React from 'react';
import { render, screen } from '@testing-library/react';
import MyAccessibleComponent from './MyAccessibleComponent';

describe('MyAccessibleComponent', () => {
  it('올바른 aria-label을 가진 접근성 있는 버튼을 렌더링한다', () => {
    render();
    const buttonElement = screen.getByRole('button', { name: 'Close' });
    expect(buttonElement).toBeInTheDocument();
  });
});

설명:

• `screen.getByRole('button', { name: 'Close' })`: `getByRole`을 사용하여 접근성 이름이 "Close"인 버튼 요소를 찾습니다. 이는 버튼이 스크린 리더를 위해 올바르게 레이블링되었음을 보장합니다.

10. 개발 워크플로우에 테스트 통합하기

테스팅은 나중에 생각할 것이 아니라 개발 워크플로우의 필수적인 부분이어야 합니다. 코드가 커밋되거나 배포될 때마다 테스트가 자동으로 실행되도록 CI/CD 파이프라인에 테스트를 통합하세요. 이는 버그를 조기에 발견하고 회귀를 방지하는 데 도움이 됩니다.

11. 현지화 및 국제화(i18n) 고려하기

글로벌 애플리케이션의 경우, 테스팅 중에 현지화 및 국제화(i18n)를 고려하는 것이 중요합니다. 컴포넌트가 다른 언어와 로케일에서 올바르게 렌더링되는지 확인하세요.

예시: 현지화 테스트하기

현지화를 위해 `react-intl`이나 `i18next`와 같은 라이브러리를 사용하는 경우, 테스트에서 현지화 컨텍스트를 모킹하여 컴포넌트가 올바른 번역된 텍스트를 표시하는지 확인할 수 있습니다.

12. 재사용 가능한 설정을 위해 커스텀 렌더 함수 사용하기

더 큰 프로젝트에서 작업할 때, 여러 테스트에서 동일한 설정 단계를 반복하는 자신을 발견할 수 있습니다. 중복을 피하기 위해 공통 설정 로직을 캡슐화하는 커스텀 렌더 함수를 만드세요.

예시: 커스텀 렌더 함수

// test-utils.js
import React from 'react';
import { render } from '@testing-library/react';
import { ThemeProvider } from 'styled-components';
import theme from './theme';

const AllTheProviders = ({ children }) => {
  return (
    
      {children}
    
  );
}

const customRender = (ui, options) =>
  render(ui, { wrapper: AllTheProviders, ...options })

// 모든 것을 다시 내보내기
export * from '@testing-library/react'

// render 메서드 오버라이드
export { customRender as render }

// MyComponent.test.js
import React from 'react';
import { render, screen } from './test-utils'; // 커스텀 렌더 가져오기
import MyComponent from './MyComponent';

describe('MyComponent', () => {
  it('테마와 함께 올바르게 렌더링된다', () => {
    render();
    // 여기에 테스트 로직 작성
  });
});

이 예제는 컴포넌트를 ThemeProvider로 감싸는 커스텀 렌더 함수를 만듭니다. 이를 통해 모든 테스트에서 ThemeProvider 설정을 반복할 필요 없이 테마에 의존하는 컴포넌트를 쉽게 테스트할 수 있습니다.

결론

React Testing Library는 컴포넌트 테스팅에 강력하고 사용자 중심적인 접근 방식을 제공합니다. 이러한 모범 사례를 따르면, 사용자 행동과 접근성에 초점을 맞춘 유지보수 가능하고 효과적인 테스트를 작성할 수 있습니다. 이는 글로벌 사용자를 위한 더 견고하고 신뢰할 수 있으며 포용적인 React 애플리케이션으로 이어질 것입니다. 사용자 상호작용을 우선시하고, 구현 세부 사항 테스트를 피하고, 접근성에 집중하고, 개발 워크플로우에 테스팅을 통합하는 것을 기억하세요. 이러한 원칙을 받아들임으로써 전 세계 사용자의 요구를 충족하는 고품질 React 애플리케이션을 구축할 수 있습니다.

핵심 요약:

• 사용자 상호작용에 집중하기: 사용자가 상호작용하는 것처럼 컴포넌트를 테스트하세요.
• 접근성 우선순위: 컴포넌트가 장애를 가진 사용자에게 접근 가능한지 확인하세요.
• 구현 세부 사항 피하기: 내부 상태나 함수 호출을 테스트하지 마세요.
• 명확하고 간결한 테스트 작성하기: 테스트를 이해하고 유지보수하기 쉽게 만드세요.
• 워크플로우에 테스팅 통합하기: 테스트를 자동화하고 정기적으로 실행하세요.
• 글로벌 사용자 고려하기: 컴포넌트가 다른 언어와 로케일에서 잘 작동하는지 확인하세요.